Systems for accessing data stores from object oriented languages have been used for many years. A frequent approach to accomplish access of data stores involves writing and embedding custom access code within an object application needing the access. This approach is generally limited to having the custom code access only a single relational table within a relational database or similar construct within any other data store (hereinafter collectively “data store”). Under the circumstances where a developer has control over the design and creation of a data store from its inception, it is possible to design and store meaningful information in a single table. Such design opportunities are usually rare, however.
Generally, the design goals of a properly normalized relational data store or specific object data store, for example conflict with those of object application models. An object application model may exist in one or more of a computer's memory, an application data store and an application information storage repository that may be independent of the data store organization or object definitions. Whether a data source is a relational database, an object database or a flat file (text) base, procedures and systems exist for converting retrieved data to a data object, or to a data object definition, that is mapped to the data source. Advancements in the art have been made with respect to tools for conveniently mapping objects to systems of tables and maps in order to expedite accessing, changing and updating data stores. See, for example, U.S. Pat. No. 5,857,197 (and its associated programming interfaces (“APIs”)) describes tools for translating object data to relational data, relational data to object data, and object data to object data to expedite the use of data stores. One or more of such data stores, data objects, data object definitions, may be utilized by an object programming application and may be illustrated as a model of data objects or as a model of data object definitions.
A further problem complicates the creation, access, changing or deleting of an object application model that utilizes such data stores. The object application model may be distributed over multiple physical computer machine locations or even distributed over multiple Internet website locations that may be independent of the data stores. The object application model may utilize a different set of data objects or different set of definitions for relationships between data objects than that of one or more of its data sources. In most situations, the respective structures of the data sources and of the object applications model simply do not conveniently allow for mapping, accessing or changing of an overall schema of application data objects as well as any associated definitions of relationships between two or more data objects or elements within a data object.
Importantly, relationships may exist between a data object and one or more of the other data objects found in the object application model or in a data object of the data source. A relationship between one data object and another data object or with a data source may be member selected from the group of three relationship types consisting of 1 to 1 (1—1), 1 to many (1-M) or many to many (M—M). Complex combinations of these relationships may exist as a data object relationships definition for a given data object. These relationships are described or illustrated in further detail later in this document.
Objects may logically span multiple relational tables or multiple object databases, and may even be distributed over a logical (or hypothetical) computer system involving multiple physically independent computer systems or even multiple website locations. Creating, accessing, maintaining or updating an object application model can require working with multiple translation modules and require tedious and repetitive updating of multiple individual computer systems or multiple data sources in order to do useful work and keep the object application model synchronized. Such approaches are both costly and unwieldy in terms of computing and development resources, particularly with respect to Internet based electronic commerce (eCommerce) object application models.
Data objects of an object application model are often a feature of eCommerce object programming applications, where information is obtained from a data source and the data is defined as a data object (e.g., as a Java class) for use with another computer application. In practice, a data object or model of data objects may exist only in the random access memory of a computer memory system, or may be saved to either a data source or to some other type of retrievable information repository. A programmer or administrator of an object data application may not be able to exhaustively display the overall model or diagram of data objects for an object application model or to display some of its specific elements. Unfortunately, tools for accessing and displaying data objects and associated data object relationships as a complex data object graph model have not been well implemented in the field of object language programming.
A computer application can execute one or more of the following non-limiting actions with respect to one or more of the members selected from the group consisting of data, a data object, and a data object definition: access data, change data, create data, create a new relationship between one or more data objects by creating or changing at least one data object relationship definition, change or delete a relationship between one or more data objects by changing or deleting at least one data object relationship definition, access a data object relationship definition and use its parameters to access a data source or a data object, and access one or more data object relationship definitions or data objects to create a new data object or data object relationship. Any changes executed by a computer application with respect to one or more of the members selected from the group consisting of data, data object or data object definition may need to be properly persisted (permanently stored) to preserve any changes to one or more of the members selected from the group consisting of data, a data object and a data object definition.
A data object and an associated data object relationship definition may be represented by a complex data object graph (“CDOG”). A CDOG, for the purposes of this document, may be thought of as a computer program data object graph that represents a data object having at least one relationship with at least one other data object or with itself via a circular link. When the data object of a CDOG is implemented in the Java computer program language, the CDOG may be further defined as being a Java Data Object Graph (“JDOG”).
There is a need for an easily navigable tool for detecting any relationships of a data object in order to provide a CDOG definition and for persisting any changes to at least one member selected from the group consisting of a data object, any data associated with the related object, or any associated CDOG definition (i.e., an changes to the data object, data or to a relationship of the data object with another data object). For example, there is a need to be able to properly sever relationships between at least two data objects in a convenient and efficient manner by simply making a change to the CDOG definition for one of the two related data objects.
An illustration of this might be a customer account CDOG of a company where the customer has become insolvent. Using the technology presently available, a computer applications programmer or administrator would ordinarily need to individually delete or update the data in the data source, in any instances of the data object and in any instances of any associated data objects, as well as to delete or update any associated data object relationship definitions, which would be particularly tedious and repetitive in a distributed application model. There is currently no computer programmer or system administrator tool that is efficiently adapted for an object applications CDOG model with features that permit convenient and efficient accessing and deleting of a single instance of a complex data object and (without further input) results in the tool automatically deleting all existing associated data objects and relationships and the tool automatically updating all local and distributed instances of the CDOG and its associated data, data objects and data object relationships on the local or distributed computer system.
Accordingly, there is a strong need in the art for a computer applications programmer tool designed to assist a programmer or administrator in the actions of deleting, inactivating or updating of a CDOG, wherein the computer applications programmer tool can be configured to automatically delete, inactivate or update at least one member selected from the group consisting of associated data, associated data objects and associated data object relationship definitions to reflect the deleting, inactivating or updating of a CDOG. A particularly strong need exists for such a tool having the further ability to be configured to persist, propagate and reflect system wide (in a local or distributed computer system) any such changes to a CDOG instance to all instances of the CDOG and to all instances of associated data, data objects and data object relationships.